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Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Abstract 


This document describes an extension to the IS-IS protocol to add 
operational capabilities that allow for ease of management and 
control over IP prefix distribution within an IS-IS domain. This 
document enhances the IS-IS protocol by extending the information 
that an Intermediate System (IS) router can place in Link State 
Protocol (LSP) Data Units for policy use. This extension will 
provide operators with a mechanism to control IP prefix distribution 
throughout multi-level IS-IS domains. 
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Introduction 


As defined in [RFC1195] and extended in [RFC3784], the IS-IS protocol 
[I1S010589] may be used to distribute IPv4 prefix reachability 
information throughout an IS-IS domain. In addition, thanks to 
extensions made in [RFC5120] and [ISIS-IPv6], IS-IS may be used to 
distribute IPv6 reachability information. 


The IPv4 prefix information is encoded as TLV type 128 and 130 in 
[RFC1195], with additional information carried in TLV 135 as 
specified in [RFC3784] and TLV 235 as defined in [RFC5120]. In 
particular, the extended IP Reachability TLV (TLV 135) contains 
support for a larger metric space, an up/down bit to indicate 
redistribution between different levels in the hierarchy, an IP 
prefix, and one or more sub-TLVs that can be used to carry specific 
information about the prefix. TLV 235 is a derivative of TLV 135, 
with the addition of Multi-Topology membership information [RFC5120]. 
The IPv6 prefix information is encoded as TLV 236 in [ISIS-IPv6], and 
TLV 237 in [RFC5120]. 


This document defines 2 new sub-TLVs for TLV 135, TLV 235, TLV 236 
and TLV 237 that may be used to carry administrative information 
about an IP prefix. 


Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14, [RFC2119]. 


Sub-TLV Additions 


This document creates 2 new "Administrative Tag" sub-TLVs to be added 
to TLV 135, TLV 235, TLV 236 and TLV 237. These TLVs specify one or 
more 32- or 64-bit unsigned integers that may be associated with an 
IP prefix. Example uses of these tags include carrying BGP standard 
(or extended) communities and controlling redistribution between 
levels and areas, different routing protocols, or multiple instances 
of IS-IS running on the same router. 


The methods for which their use is employed is beyond the scope of 
this document and left to the implementer and/or operator. 


The encoding of the sub-TLV(s) is discussed in the following 
subsections. 
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3.1. 32-bit Administrative Tag Sub-TLV 1 


The Administrative Tag SHALL be encoded as one or more 4-octet 
unsigned integers using Sub-TLV 1 in TLV 135 [RFC3784], TLV 235 
[RFC5120], TLV 236 [ISIS-IPv6], and TLV 237 [RFC5120]. The 
Administrative Tag Sub-TLV has following structure: 


o 1 octet of type (value: 1) 
o 1 octet of length (value: multiple of 4) 
O one or more instances of 4 octets of administrative tag 


On receipt, an implementation MAY consider only one encoded tag, in 
which case, the first encoded tag MUST be considered and any 
additional tags ignored. A tag value of zero is reserved and SHOULD 
be treated as "no tag". 


3.2. 64-bit Administrative Tag Sub-TLV 2 


The Administrative Tag SHALL be encoded as one or more 8-octet 
unsigned integers using Sub-TLV 2 in TLV 135 [RFC3784], TLV 235 
[RFC5120], TLV 236 [ISIS-IPv6], and TLV 237 [RFC5120]. The 64-bit 
Administrative Tag Sub-TLV has following structure: 


o 1 octet of type (value: 2) 
o 1 octet of length (value: multiple of 8) 
O one or more instances of 8 octets of administrative tag 


On receipt, an implementation MAY consider only one encoded tag; in 
which case, the first encoded tag MUST be considered and any 
additional tags ignored. A tag value of zero is reserved and SHOULD 
be treated as "no tag". 


4. Ordering of Tags 


The semantics of the tag order are implementation-dependent. That 
is, there is no implied meaning to the ordering of the tags that 
indicates a certain operation or set of operations need be performed 
based on the order of the tags. Each tag SHOULD be treated as an 
autonomous identifier that MAY be used in policy to perform a policy 
action. Whether or not tag A precedes or succeeds tag B SHOULD not 
change the meaning of the tag set. However, when propagating TLVs 
that contain multiple tags between levels, an implementation SHOULD 
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preserve the ordering such that the first tag remains the first tag, 
so that implementations that only recognize a single tag will have a 
consistent view across levels. 


Each IS that receives an LSP with TLV(s) 135 and/or 235 and/or 236 
and/or 237, that have associated sub-TLV(s) 1 and/or 2, MAY operate 
on the tag values as warranted by the implementation. If an 
implementation needs to change tag values, for example, when 
propagating TLVs between levels at an area boundary, then the TLV(s) 
SHOULD be copied to the newly generated Level-1 or Level-2 LSP. At 
that point, the contents of the sub-TLV(s) MAY change as dictated by 
the policy action. In the event that no change is required, the sub- 
TLV(s) SHOULD be copied in order into the new LSP, such that ordering 
is preserved. 


5. Compliance 


A compliant IS-IS implementation MUST be able to assign one tag to 
any IP prefix in any of the following TLVs: TLV 135, TLV 235, TLV 
236, TLV 237. It MUST be able to interpret a single tag present in 
the sub-TLV, or the first tag where there is more than one tag 
present in the sub-TLV. 


A compliant IS-IS implementation MAY be able to assign more than one 
tag to any IP prefix in any of the following TLVs: TLV 135, TLV 235, 
TLV 236, TLV 237. It MAY be able to interpret the second and 
subsequent tags where more than one tag is present in the sub-TLV. 


When propagating TLVs between levels, a compliant IS-IS 
implementation MAY be able to rewrite or remove one or more tags 
associated with a prefix in any of the following TLVs: TLV 135, TLV 
235, TLV 236, TLV 237. 


6. Operations 


An administrator associates an Administrative Tag value with some 
interesting property. When IS-IS advertises reachability for some IP 
prefix that has that property, it adds the Administrative Tag to the 
IP reachability information TLV for that prefix, and the tag "sticks" 
to the prefix as it is flooded throughout the routing domain. 


Consider the network in Figure 1. We wish to "leak" L1 prefixes 
[RFC2966] with some property, A, from L2 to the L1 router R1. 
Without policy groups, there is no way for R2 to know property A 
prefixes from property B prefixes. 
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L1 / N 
R1----1.1.1.0/24 (A) R5 


1.1.2.0/24 (B) 
Figure 1: Example of usage 


We associate Administrative Tag 100 with property A, and have R5 
attach that value to the IP extended reachability information TLV for 
prefix 1.1.2.0/24. R2 has a policy in place to "match prefixes with 
Administrative Tag 100, and leak to L1". 


The previous example is rather simplistic; it seems that it would be 
just as easy for R2 simply to match the prefix 1.1.2.0/24. However, 
if there are a large number of routers that need to apply some policy 
according to property A and a large number of "A" prefixes, this 
mechanism can be quite helpful. 


Implementations that support only a single tag and those that support 
multiple tags may coexist in the same IS-IS domain. An 
implementation supporting multiple tags SHOULD therefore assign any 
tag that is required to be interpreted by all systems as the first 
tag in any set of multiple tags. 


7. Security Considerations 


This document raises no new security issues for IS-IS, as any 
annotations to IP prefixes should not pass outside the administrative 
control of the network operator of the IS-IS domain. Such an 
allowance would violate the spirit of Interior Gateway Protocols in 
general and IS-IS in particular. 


8. IANA Considerations 
IANA has assigned "1" as the type code of the 32-bit Administrative 
Tag Sub-TLV and "2" as the type code of the 64-bit Administrative Tag 
Sub-TLV. 

9. Manageability Considerations 
These extensions have been designed, developed, and deployed for many 


years and do not have any new impact on management and operation of 
the IS-IS protocol via this standardization process. 
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